Debuggers are software tools used to debug software program execution. User space debuggers assist in debugging user-written programs that run in a user space, in contrast to kernel debuggers that aid in debugging a kernel or operating system. Kernel debuggers are typically used by developers of system software such as kernel modules, device drivers etc, while user space debuggers are typically used by application developers.
Some common examples of user-space debuggers are: gdb (on the Linux operating system) and dbx (on the AIX™ operating system).
This invention applies to most user-space debuggers. A possible extension of this invention to kernel space debuggers is discussed. The term usdb is used in this document to denote a generic user-space debugger.
FIG. 1 schematically represents the interaction of usdb 10 and an application program 20 being debugged (denoted TA, for convenience). A single instance of usdb acts directly on a single instance of the application program (TA) being debugged.
The usdb debugger provides an interactive menu for the debugger to control execution of the debugee application (TA). The debugger provides commands for “single-stepping”, applying “breakpoints”, dumping “memory” contents etc. usdb normally makes use of operating system services such as ptrace to provide these commands. Using these basic commands, the debugger is able to control/analyze program execution. usdb typically uses the wait system call to get notified when the debugee stops because of a debug event (breakpoint, signals etc).
ptrace is a system call available on most flavors or variants of the Unix operating system (such as Linux or AIX™). ptrace is used normally by debuggers to control program execution. ptrace normally provides the following services listed directly below:    1. Attach (PTRACE—ATTACH)—This service is used to “attach” to a target process.    2. Get registers (PTRACE—GETREGS)—This service obtains registers values of the target process.    3. Set registers (PTRACE—SETREGS)—This service modifies registers values of the target process.    4. Continue (PTRACE—CONT)—This service continues a stopped process. The process runs until the process hits a debug event (such as breakpoint) that causes the process to stop again.    5. View memory (PTRACE—PEEKTEXT)—This service examines the memory contents of the target process.    6. Modify memory (PTRACE—POKETEXT)—This service modifies the contents of target process memory.
FIG. 2 shows three programs that are running at the same time in a machine. These three concurrently executing tasks are referred to for convenience as TA, TB and TC. Respective “copies” of usdb 10, 30, 50 are used for each task. As with the case of a single task 20 (TA, as represented in FIG. 1), each instance of usdb acts directly on a respective process 20, 40, 60 (TA, TB or TC, as represented in FIG. 2).
FIG. 3 schematically represents another possibility for simultaneously controlling multiple programs. In this case, one instance of usdb 10 controls tasks 20, 20′, 20″ (TA, TB and TC) simultaneously. The approach conveniently provides a single point of control for TA, TB and TC. This approach can be desirable when the multiple programs are related and the debugger wishes to control/debug all of the programs from a single point of control.
This integrated approach is possible only when TA, TB and TC are “closely” related to each other. This close relation is possible when these tasks have a parent-child relationship. Further, Unix (and other) operating systems use the concept of “threads” to define such a close association. Threads belonging to the same process have many things in common, such as address space, signal handlers etc. If so, usdb detects threads created by the debugee application/process and can use this information to control all threads simultaneously. usdb can support threading and if so, maintains knowledge about each individual thread (such as thread ID etc.). Without such support and knowledge, usdb cannot control TA, TB and TC simultaneously.
In view of the above, a need clearly exists for an improved manner of debugging applications that at least attempts to address one or more prior art limitations.